Thanks for adding schema and example for population results and related tests!
I have two questions:

1. Does the schema for a single results (single municipality) looks different from current example.json? Or simply just have a single entry in series (aka len(series) == 1)? ;)
2. Do schemas for other popups differ from example.json in population folder? Or can we agree on a default schema for all results? Or maybe a default schema, and differing schemas in case the schema does not fit for a special result? This would make development of the API much easier...

Some minor things I would change:

• If we agree on a default schema, I would move up the schema.json one folder into folder schema.
• I would like to remove init.py from metadata folders and keep it as a non-python/config-like structure (Reading-in of the schemas in examply.py and schema.py would be done in settings.py or an extra module next to it).

Hi @henhuy,

Thank you for your review! Following, I will address your points:

Does the schema for a single results (single municipality) looks different from current example.json? Or simply just have a single entry in series (aka len(series) == 1)? ;)

Yes, the schema is the same. You just have a single entry in a series in the case of one municipality. The example.json is shortened. Typically, two cases exist: (i) a list of one municipality or (ii) a list of twenty municipalities.

Do schemas for other popups differ from example.json in population folder? Or can we agree on a default schema for all results? Or maybe a default schema, and differing schemas in case the schema does not fit for a special result? This would make development of the API much easier...

I'm shooting for "a default schema and differing schemas in case the schema does not fit for a special result." Still, I can't guarantee that the proposed schema will change until then. Suggestion, I will add a default schema to this PR that I extract from the population schema (which I already created with generic use in mind). Let us have 2 - 3 more implementations and finalize it on the fly. For this, we need actual data! @nesnoj, wink wink 😉

If we agree on a default schema, I would move up the schema.json one folder into folder schema.

OK, I will move it.

I would like to remove init.py from metadata folders and keep it as a non-python/config-like structure (Reading-in of the schemas in examply.py and schema.py would be done in settings.py or an extra module next to it).

OK, I will make the appropriate changes.

@henhuy, finally ready 😃 after a little fight with the linter, please review the changes I made

I made everything more generic and included chartType and sources attributes. And moved everything to the demanded folders/places.

I switched the PR to draft mode. As decided in the weekly, I will add atomic component schemas (e.g., charts) before asking for another review.

@henhuy, I extracted an atomic chart schema and example and referenced it in the default schema. Please review this PR and merge on approval.

Please note I mocked the test because the $id properties of the schemas have to be proper and existing URIs. This is not the case yet. Right now, they point to non-existing endpoints of: https://wam.rl-institut.de/digiplan/schemas/[...]

Again setting this PR to draft because I'm implementing in #73 the popup on map an realized I can do the format even more generic - stay tuned :)

@henhuy, I finalized the schemas :) Please review and merge if approved!

Now we have component schemas (chart and sources) and one specific schema (popup). I aim for generic components and individual schemas for specific implementations with their own specific constraints (like the popup schema has). I think this gives it a good balance between complexity and reusability. I also sliced off anything that is not absolutely needed for the client in the API response object (and for you to implement in the backend).

Having a set of components will help us to construct the rest of the schemas in a faster and more generic way. However, I gave up trying to do everything generic because I realized this didn't work well. For example, the popup has specific constraints that cannot be adequately generic. And if you try to do everything generic, then I would have to define informal business logic, which constructs the appropriate data structures, in the frontend in JavaScript. This, in my opinion, is not a good solution and would make everything super messy and is the opposite of our rule for good web app architecture: "dumb frontend, intelligent backend."

Therefore I vote for generic components and schemas for specific API endpoint implementations for particular needs (e.g., map popup, result page with charts, etc.). Ultimately, I think there will only be a handful of specific schemas (maybe 3 - 4). The first one is the popup schema given in this PR.

@henhuy, please also have a look at the JSON API placeholder popup.json file in #73 which might help you to better understand the use of $ref in the JSON schema of this PR.

Looks very nice! This is how I imagined it. Thank you very much